In most computing systems, low level instruction code is used as an intermediary between the hardware components of the computing system and the operating software and other high-level software executing on the computing system. In some computer systems, this low level instruction code is known as the Basic Input and Output System (“BIOS”). The BIOS provides a set of software routines that allow high level software to interact with the hardware components of the computing system using standard calls.
Because of limitations of the BIOS in many PC-compatible computers, a new specification for creating the firmware that is responsible for booting the computer and for intermediating the communication between the operating system and the hardware has been proposed. The new specification is called the Extensible Firmware Interface (“EFI”) specification and is available from INTEL CORPORATION.
The EFI specification describes an interface between the operating system and the system firmware. In particular, the EFI specification defines the interface that platform firmware must implement and the interface that the operating system may use in booting. How the firmware implements the interface is left up to the manufacturer of the firmware. The EFI specification provides protocols for EFI drivers to communicate with each other, and the EFI core provides functions such as allocation of memory, creating events, setting the clock, and many others. This is accomplished through a formal and complete abstract specification of the software-visible interface presented to the operating system by the platform and the firmware.
The EFI is capable of providing services to other applications. Services are implemented by modules that may be loaded by a boot loader when the EFI is started. The services may provide memory management, domain services, driver services, protocol services, and others. The EFI specification has a specific requirement for servicing hardware devices that drivers cannot use an interrupt request line (“IRQ”) from hardware, such as from a PS/2 controller, and thus, EFI drivers must poll the hardware. Handling or servicing PS/2 devices in this manner by employing timer events causes inefficiency and data loss. Problems with one PS/2 device blocking another PS/2 device develop when an application does not access a device for some time.
Applications utilize specified protocols to observe input from hardware. Thus, there are multiple ways to implement an EFI driver and support the protocols. One way is to setup a timer and periodically poll the state of the PS/2 controller to ascertain whether any input data is present. Periodic polling is necessary to prevent one device from blocking another device's input. This blocking occurs when data from one source is in the PS/2 keyboard controller, but has not been taken away for a long time. In such a situation another device's data cannot pass through the controller to the corresponding driver.
PS/2 controllers have one common data out port that latches the data from the first device that produced it. Thus, periodic polling reads the data from a PS/2 device even if it is not requested by the application in order to give another source input a chance to pass data to the user. However, having two timers is an overhead that can slow down a computing system. Moreover, the basis for selecting the polling frequency is arbitrary at best and depends on user activity. Accordingly, there is a need for a method, system, and apparatus for servicing PS/2 devices within an EFI environment.
It is with respect to these considerations and others that the various embodiments of the invention have been made.